Part 30: Assignment #12: Device 2A27

Device 2A27





Wow, another day, another email, huh. I can't say I've ever seen anything like this before.
I wonder what it wants?







OK, so two or three things leap out at me, looking at this. The first is that Poseidon-whoever has left just enough detail in the specs to intrigue me as to what on earth this is supposed to be used for. What does 'flux point' even mean in this context? The second thing I can see, which should make things easier, is that the state space appears to be composed of two areas added together - the left-right vertical bars, worth 30, and the square near the center, worth 50.

This neatly fits into the third thing, which is that I have two simple inputs and one simple output, and none of them are expander-compatible this time. So I'll have to use at least two MCs. Probably one to determine the vertical bars, then a second (attached to it) to test for the square and pass the result on.

[ ~ ]



 

Before I say anything else, let's be clear: this prototype doesn't work. I'm still working out the kinks, and one of them is that MC that checks the square part (currently the second MC in line) does need to check the 'x' coordinate as well as the 'y' coordinate. (I thought it didn't - that's how we got the picture above.)

So, seeing as the second MC has its simple I/O pins full already (one with the y-coord and one with the output), it looks like I'll have to get MC #1 to pass the x-coord value along by XBus if I want to use it there. The only complicated part is that it might have to pass the x-coord more than once - there's more than one test that uses the coordinate, after all (40 ≤ x < 80).

[ ~ ~ ]



 

I have a dilemma. The above is what I came up with. I know it'll work - the first MC passes the x-coordinate along to the second MC twice (once for each of the two tests it has to do with it), and the second MC does the tests.
The dilemma is that the code doesn't fit - the 'mov x0 null' lines are necessary to throw out the x-coordinate values in case the second MC doesn't actually need to run those tests (because otherwise the first MC'll block when trying to write the x-coords)... but the cost is that the script is 10 instructions long. Yeah, I could just slot in a MC6000 - but it feels like I'm really missing some sort of better way to do this.

I'll keep playing with it and see if I find anything. Saving just one instruction would be enough!

[ ~ ~ ~ ]





Remember how I said I thought I was missing a simpler way? I was. The trick is to do the testing for the square first. The first MC (on the left) now tests for the square (it can attach both its I/O pins to x and y), then sends that along to the second (middle) MC, which only needs the x-value for its test (the two vertical bars). It can add the result of the two tests and send the total out easily.

The design feels pretty clean. I don't think I can do much better on this one now.



I did some digging on Decentralized Autonomous Corporations. When they were first introduced, due to using evolutionary algorithms, the corporations would routinely find 'loopholes' in laws that led to some pretty weird and undesirable behavior - weird and undesirable for the rest of us, that is.
I am given to understand that DACs have a somewhat narrower set of algorithms that may be used nowadays - that, and there's been some loophole-patching of various laws, too.

At least they're not let onto the stock market, not after the 'Flash Fire' crash of 2021. Can you imagine?